This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
The following abbreviations that appear in the specification and drawings are defined as follows:
3GPPthird generation partnership projectACKacknowledgeaGWaccess gatewayBWbandwidthC-Planecontrol planeCQIchannel quality indicationDLdownlinkDTXdiscontinuous transmissioneNBEUTRAN Node B (evolved Node B)EUTRANevolved UTRANFDMAfrequency division multiple accessLTElong term evolutionMACmedium access controlMMmobility managementNACKnegative acknowledgeNode Bbase stationOCorthogonal coverOFDMAorthogonal frequency division multiple accessPDCPpacket data convergence protocolPHYphysicalPDSCHphysical downlink shared channelPUCCHphysical uplink control channelPUSCHphysical uplink shared channelRLCradio link controlRRCradio resource controlRRMradio resource managementRSreference signalSC-FDMAsingle carrier, frequency division multiple accessSDUservice data unitSRscheduling requestUEuser equipmentULuplinkU-Planeuser planeUTRANuniversal terrestrial radio access network
A proposed communication system known as evolved UTRAN (E-UTRAN, also referred to as UTRAN-LTE or as E-UTRA) is currently under development within the 3GPP. The current working assumption is that the DL access technique will be OFDMA, and the UL access technique will be SC-FDMA.
One specification of interest to these and other issues related to the invention is 3GPP TS 36.300, V8.3.0 (2007-12), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Access Network (E-UTRAN); Overall description; Stage 2 (Release 8).
FIG. 1 reproduces FIG. 4 of 3GPP TS 36.300, and shows the overall architecture of the E-UTRAN system. The E-UTRAN system includes eNBs, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the UE. The eNBs are interconnected with each other by means of an X2 interface. The eNBs are also connected by means of an S1 interface to an EPC (Evolved Packet Core), more specifically to a MME (Mobility Management Entity) by means of a S1-MME interface and to a Serving Gateway (S-GW) by means of a S1-U interface. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNBs.
The eNB hosts the following functions:                functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);        IP header compression and encryption of user data stream;        selection of a MME at UE attachment;        routing of User Plane data towards Serving Gateway;        scheduling and transmission of paging messages (originated from the MME);        scheduling and transmission of broadcast information (originated from the MME or O&M); and        measurement and measurement reporting configuration for mobility and scheduling.        
Two documents of particular interest to the ensuing discussion are TSG-RAN WG1, R1-080343, Sevilla, Spain, Jan. 14-18, 2008, Source: Ericsson, Title: Multiplexing of ACK/NACK and Scheduling Request on PUCCH (referred to hereafter as R1-080343), and 3GPP TSG RAN WG1 Meeting #51bis, R1-080035, Sevilla, Spain, Jan. 14-18, 2008, Source: Samsung, Nokia, Nokia Siemens Networks, Panasonic, TI, Title: Joint proposal on uplink ACK/NACK channelization, (referred to hereafter as R1-080035).
Reference can also be made to 3GPP TR 36.211, V8.1.0 (2007-11), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Physical Channels and Modulation (Release 8), for a description in Section 5 of the UL physical channels, including the PUCCH and the PUSCH.
In accordance with a current agreement in 3GPP the simultaneous transmission of SR and ACK/NACK is to be supported. However, the specifics of the multiplexing method and the exact transport format have been reserved for future study. It can be noted though that a widely accepted approach for multiplexing the SR and ACK/NACK is for the ACK/NACK to be sent from the SR resource if the SR and ACK/NACK need to be transmitted simultaneously. It has been agreed that SR is transmitted by using on/off keying with unmodulated RS sequences.
It is noted that when referring to the SR, TS 36.21x series utilizes the term PUCCH Format 1. Correspondingly, when referring to ACK/NACK as a general term, PUCCH Formats 1a/1b are meant. Table 1 below summarizes the available PUCCH Formats:
TABLE 1PUCCH FormatsPUCCH FormatsControl typePUCCH Format 1Scheduling requestPUCCH Format 1a1-bit ACK/NACKPUCCH Format 1b2-bit ACK/NACKPUCCH Format 2CQIPUCCH Format 2aCQI + 1-bit ACK/NACKPUCCH Format 2bCQI + 2-bit ACK/NACK
A problem that arises relates to DTX detection in the case where ACK/NACK/DTX is transmitted simultaneously with the SR.
The DTX situation relates to a failure of a DL resource allocation grant transmitted to a particular UE. When the DL resource allocation fails the ACK/NACK(s) associated with the PDCCH/PDSCH are missing from the given UL sub-frame (this is DTX from the ACK/NACK point of view), since the UE has for whatever reason missed the DL allocation and therefore has no reason to transmit or include an ACK/NACK in the UL subframe. However, the eNB cannot know that the ACK/NACK is not present and may, as a result, incorrectly interpret the reception from the UE.
It may be possible to employ a DL ACK/NACK DTX detector to attempt to solve the problem, e.g., to identify whether the DL ACK/NACK is present or not. However, if the ACK/NACK DTX detector fails then it is possible that at least two types of errors can occur.
A first error type may be referred to as misdetection, DTX→ACK/NACK: wherein the DL resource allocation grant fails but eNB cannot detect that this has occurred.
A second error type may be referred to as a false alarm, ACK/NACK→DTX: wherein the eNB considers that the DL allocation grant has failed even though it has been correctly received by the UE.
In this context DTX corresponds to signaling of the SR instead of the combination of the ACK/NACK and SR.
As can be appreciated, the error cases in this type of SR and ACK/NACK multiplexing scheme can result in serious problems, in particular in a so called DTX (SR)→ACK error case, and should thus be considered when developing the multiplexing scheme for the SR and ACK/NACK.
The DTX to ACK error occurs when the eNB detects an ACK, even though an ACK was not sent by the UE, but only the SR. The combination of DL scheduling information miss detection and the DTX to ACK error (for the DL-SCH) has an impact on higher layer protocols, e.g., it can result in higher layer error. Interpreting the received SR as an ACK is a particularly troublesome error situation from the DL point of view since a DL transmission is erroneously assumed to have been correctly received by the UE. This implies that the higher protocol layers must eventually detect the missed DL transmission by the UE, and then provide some means to recover. In general, this type of higher protocol layer error recovery would be significantly slower than a L1 recovery, and would require significantly more signaling overhead to accomplish. It is thus desirable that such error cases occur, if at all, at a very low rate.
One ACK/NACK and SR multiplexing method is proposed in R1-080343. However, various error cases, especially the DTX to ACK error case, are not considered.